Testing verification paths provided by a verification microservice for a deduplicated object storage system

ABSTRACT

Described is a system for detecting corruption in a deduplicated object storage system accessible by one or more microservices while minimizing costly read operations on objects. A testing tool inserts object corruptions in object storage. A verification path is performed by a controller module and one or more worker nodes. The testing tool verifies whether the executed verification path accurately detected the testing tool&#39;s inserted object corruptions.

TECHNICAL FIELD

This disclosure relates to deduplication systems, and more particularly,to relationship between data stored within deduplication systems.

BACKGROUND

In computing, a data storage system is a key component to store data forcomputation and transferring. Data files generally contain redundantdata. For example, an email file may contain email threads that earlieremails are copied multiple times in the later replies. In an enterprisesetting, many versions of the same information are stored for recordkeeping. Storing data files like these without modification wastesstorage space and data deduplication is a way to reduce data redundancyin a storage system.

In a deduplication system, unique pieces of data, or byte patterns, in afile are identified as “chunks,” and they are stored during a process ofanalysis of the file. The analysis goes through the file, and otherchunks are compared to the stored copy and whenever a match occurs, theredundant chunk is replaced with a small reference that points to thestored chunk. Because the same byte patterns may occur many times in afile, the amount of data that must be stored is greatly reduced.

Several factors affect deduplication efficiency. The amount of reductionof storage depends heavily on the distribution of the duplication withina file. The size of chunks also affects the reduction. A smaller chunksize saves more storage as it enables the system to identify moreduplicates. However, a smaller chunk size increases the size ofmetadata, deduplication time, and fragmentation. Thus, the chunk sizeselection is a trade-off decision to a deduplication system. Anotherfactor affecting the deduplication efficiency is how a file is dividedup for deduplication. Ideally a file should be divided up in a way tomaximize the possibility of finding duplicates. In a deduplicationsystem, a file is divided up into data blocks, which are the units ofdeduplication.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated into and constitute apart of this specification, illustrate embodiments of the disclosure andtogether with the description, serve to explain the principles of thedisclosure.

FIG. 1A is a block diagram illustrating an example operating environmentaccording to one or more embodiments of the disclosure.

FIG. 1B is a block diagram illustrating an example operating environmentaccording to one or more embodiments of the disclosure.

FIG. 1C is a block diagram illustrating an example operating environmentaccording to one or more embodiments of the disclosure.

FIG. 1D is a block diagram illustrating an example operating environmentaccording to one or more embodiments of the disclosure.

FIG. 2 is a block diagram illustrating relationships between objectrecipes, slice recipes, similarity groups and compression regionsaccording to one or more embodiments of the disclosure.

FIG. 3 is a block diagram illustrating naming conventions according toone or more embodiments of the disclosure.

FIG. 4 is a block diagram illustrating naming conventions according toone or more embodiments of the disclosure.

FIG. 5 is a block diagram illustrating a verification path conditionsaccording to one or more embodiments of the disclosure.

FIG. 6A is a flow diagram illustrating an example method according toone or more embodiments of the disclosure.

FIG. 6B is a flow diagram illustrating an example method according toone or more embodiments of the disclosure.

FIG. 7 is a block diagram illustrating worker node estimation accordingto one or more embodiments of the disclosure.

FIG. 8 is a block diagram illustrating a phase according to one or moreembodiments of the disclosure.

DETAILED DESCRIPTION

Various embodiments and aspects of the disclosures will be describedwith reference to details discussed below, and the accompanying drawingswill illustrate the various embodiments. The following description anddrawings are illustrative of the disclosure and are not to be construedas limiting the disclosure. Numerous specific details are described toprovide a thorough understanding of various embodiments of the presentdisclosure. However, in certain instances, well-known or conventionaldetails are not described in order to provide a concise discussion ofembodiments of the present disclosure. Although these embodiments aredescribed in sufficient detail to enable one skilled in the art topractice the disclosed embodiments, it is understood that these examplesare not limiting, such that other embodiments may be used and changesmay be made without departing from their spirit and scope. For example,the operations of methods shown and described herein are not necessarilyperformed in the order indicated and may be performed in parallel. Itshould also be understood that the methods may include more or feweroperations than are indicated. In some embodiments, operations describedherein as separate operations may be combined. Conversely, what may bedescribed herein as a single operation may be implemented in multipleoperations.

Reference in the specification to “one embodiment” or “an embodiment” or“some embodiments,” means that a particular feature, structure, orcharacteristic described in conjunction with the embodiment can beincluded in at least one embodiment of the disclosure. The appearancesof the phrase “embodiment” in various places in the specification do notnecessarily all refer to the same embodiment.

In some embodiments, described is a system (and method and computerprogram product) for a verification microservice engine for generatingand deploying a controller module and one or more worker nodes to detectcorruption in a deduplicated object storage system accessible by one ormore microservices while minimizing costly read operations on objects.The verify controller module estimates an optimal number of worker nodesto be instantiated. A verify controller and worker nodes are deployed toa cloud computing environment to execute, in concert with each other, asimilarity group verification path or a slice recipe verification path.

According to various embodiments, the verification microservice enginegenerates a controller module. In order to estimate a number of workernodes required to support execution of the slice recipe verificationpath or the similarity group verification path, the controller moduledetermines whether a worker node memory condition occurs, whereby theworker node memory condition indicates an amount of worker node memoryfor storing the referenced similarity groups exceeds an amount of workernode memory for storing the slice recipe names. The controller moduledetermines a total memory size of slice recipe names in object storageof a deduplicated storage system. Each slice recipe name references asimilarity group and each similarity group is pre-assigned to a workernode. The controller module identifies, for each respective worker nodeto be instantiated by the controller module, worker node memorypartitions required to store each slice recipe name. The controllermodule identifies a worker node memory condition while identifying oneor more of the same worker node memory partitions for storing thereferenced similarity groups. Based on whether the worker node memorycondition occurs, the controller module instantiates one or more workernodes according to the worker node memory partitions required to storeeach slice recipe name or the worker node memory partitions required tostore the referenced similarity groups.

The similarity group verification path is selected by the verificationmicroservice engine (or the controller module) when a total memory sizeof all the slice recipe names in a data domain(s) (i.e. one or morededuplication storage systems) is larger than the total memory sizetaken up by all the similarity groups in the same data domain(s). Theslice recipe verification path is selected by the verificationmicroservice engine (or the controller module) when a total memory sizeof all the slice recipe names in a data domain(s) is lower than thememory size taken up by one or more of the similarity groups in the samedata domain(s). The controller module instantiates one or more workernodes according to which verification path is selected. If the workernode memory condition is detected to trigger the slice recipeverification path, then the controller module instantiates worker nodesaccording to the internal worker node memory partitions over a pluralityof workers nodes that are required for storing slice name recipes.However, if the worker node memory condition is not detected, thesimilarity group verification path is triggered and the controllermodule instantiates worker nodes according to the internal worker nodememory partitions over the workers nodes that are required for storingsimilarity groups referenced in the slice recipe names. According tovarious embodiments, internal worker node memory partitions may be oneor more memory partitions allocated for use by a respective worker node.

According to various embodiments, the verification microservice enginealso generates and deploys a testing tool. The testing tool uploads oneor more objects into object storage of the deduplicated storage system.The objects comprise one or more of: an object recipe name, an objectrecipe, a slice recipe name, a slice recipe, a similarity group name anda similarity group. The testing tool corrupts internal object metadataof a first subset of the uploaded objects, where internal objectmetadata references data internal to an uploaded object. The testingtool corrupts external object metadata of a second subset of theuploaded objects, where the external object metadata provides areference to another uploaded object, such as a relationship betweenvarious uploaded objects. The testing tool deletes a third subset of theuploaded objects. The verification microservice performs a slice recipeverification path or a similarity group verification path over theobject storage. The testing tool receives a corrupted objects listdescribing one or more corruptions identified by a controller module andone or more worker nodes during performance of a respective verificationpath. The testing tool confirms whether the corruptions in the corruptedobjects list correspond with the first and second subsets of corrupteduploaded objects and the third subset of deleted uploaded objects inorder to confirm that all expected corruptions were captured by thetesting tool's performance of either the slice recipe verification pathor the similarity group verification path.

In addition, the system provides many benefits in contrast with thelimitations of conventional system. The system allows for verifying thatall objects in object storage are valid and for confirming whetherrelationships between objects are still valid. Such relationshipsinclude: “object-to-slice recipe,” “slice recipe-to-similarity group”and “similarity group-to-compression region.”

In some embodiments, such a system may be provided within an operatingenvironment. An example of such an operating environment is furtherdescribed herein with reference to FIG. 1A. However, in general,embodiments of the disclosure may include and/or be implemented in anoperating environment including a cloud services environment that maybe, or include, a data protection operating environment that includes abackup and clustered storage environment. For example, at least somefunctionality may be provided by, or implemented in connection with,various platforms for data protection platform provided by Dell EMC™Corporation, and associated systems, methods, and components, althoughuse of this particular platform is provided only by way of illustrationand is not required.

In some embodiments, the storage environment may take the form of acloud storage environment. However, embodiments of the disclosure mayalso be implemented for an on-premises storage environment, and hybridstorage environments that include public and private elements, as wellas any other type of storage environment. In addition, any of thesecloud environments, or other operating environments, may take the formof an operating environment that is partly, or completely, virtualized.The storage environment may include one or more host devices that eachhost one or more applications used by a client of the storageenvironment. As such, a particular client may employ, or otherwise beassociated with, one or more instances of each of one or moreapplications. In general, the applications employed by the clients arenot limited to any particular functionality or type of functionality.Some example applications may include database applications (e.g. a SQLServer), filesystems, as well as other types of data stores. Theapplications on the clients may generate new and/or modified data thatis desired to be protected.

Any of the devices, including the clients, servers and hosts, in theoperating environment can take the form of software, physical machines,or virtual machines (VM), or any combination thereof, though noparticular device implementation or configuration is required for anyembodiment. Similarly, data protection system components such asdatabases, storage servers, storage volumes, storage disks, backupservers, restore servers, backup clients, and restore clients, forexample, can likewise take the form of software, physical machines orvirtual machines (VM), though no particular component implementation isrequired for any embodiment. Where VMs are employed, a hypervisor orother virtual machine monitor (VMM) can be employed to create andcontrol the VMs.

As used herein, the term “data” is intended to be broad in scope.Accordingly, data may include data objects (or objects), data segmentssuch as may be produced by data stream segmentation processes, datachunks, data blocks, atomic data, emails, files, contacts, directories,sub-directories, volumes, etc. In addition, the term “backup” (or “databackups,” “backed-up data,” etc.) is intended to be construed broadlyand includes, but is not limited to, partial backups, incrementalbackups, full backups, clones, snapshots, any other type of copies ofdata, and any combination of the foregoing. Any of the foregoing may, ormay not, be deduplicated. In addition, the storage of data can employany suitable storage technique, infrastructure, hardware (e.g. SolidState Drive (SSD), Hard Disk Drive (HDD)), or on virtual storage systemsprovided by a cloud service provider, etc.

Exemplary Environments

More specifically, and with reference to FIG. 1A, shown is a blockdiagram illustrating an example of an operating environment 100 fordistributing phases of deduplication processing within a clusteredstorage environment according to one or more embodiments of thedisclosure. As shown, the environment 100 may include a client system110, backup system 150, backup server 172, and a clustered storagesystem 180. It should be noted that the components of operatingenvironment 100 may interact via a network 102, which may be any type ofwired or wireless network including a local area network (LAN), a widearea network (WAN), or a direct communication link, or other suitableconnection.

As shown, the operating environment 100 may include a client or clientsystem (or computer, or device) 110 that may be associated with a clientor customer of a data backup and protection service, and a backup system150 that may be associated with a data backup and protection serviceprovider. For example, the client system 110 may provide computingresources (e.g. webservers, databases, etc.) for users (e.g. websitevisitors) of the customer, data from which may be protected by thebackup and data protection service provider. Accordingly, the clientsystem 110 may act as a client from which backups are performed. In someembodiments, the client system 110 may comprise a virtual machine. Inaddition, the client system 110 may host one or more client applications112, and may include data storage 114, as well as an interface forcommunicating with other systems and devices, such as the backup system150. In general, the client applications 112 may create new and/ormodified data that is desired to be protected. As such, the clientsystem 110 is an example of a host device. The data storage 114 can beused to store client data, which may, along with the client system 110(e.g. client applications 112) may be backed up using the backup system150. As further described herein, components of the client system 110(e.g. client applications, 112, data storage 114, etc.) may be a datasource, or be associated with, one or more data sources such as adatabase, VM, storage device, etc. In addition, components of the clientsystem 110 may be data sources that are associated with the clientsystem 110, but reside on separate servers such as a data server, or acloud-computing infrastructure. The client system 110 may include abackup client application, or plug-in application, or API thatcooperates with backup system 150, to create backups of client data. Thebacked-up data can also be restored to the client system 110.

In one embodiment, backup component 150 may represent one or morecomponents of a Data Domain Restorer (DDR)-based deduplication storagesystem, and backup server 172 may be implemented in conjunction with aData Domain deduplication storage server provided by Dell EMC for usewith DDR storage devices. For example, the backup server 172 may be astand-alone entity, or can be an element of the clustered storage system180. In some embodiments, the backup server 172 may be a Dell EMC Avamarserver or a Dell EMC Networker server, although no particular server isrequired, and other backup and storage system configurations arecontemplated.

The backup component 150, may include a backup application (orappliance) 152 that performs (or manages, coordinates, etc.) thecreation and restoration of data that may be backed-up. For example,data to be backed-up from the client system 110 may be communicated fromthe client system 110 to the backup application 152 for initialprocessing, after which the processed data is uploaded from the backupapplication 152 for storage at the clustered storage system (e.g. asbackup data 161). In some embodiments, the backup application 152 maycooperate with a backup client application of the client system 110 toback up client data to the clustered storage system 180. A backupapplication 152 may also cooperate with a backup client application torestore backup data from the clustered storage system 180 to the clientsystem 110. In some embodiments, the backup application 152 may be apart of, or work in conjunction with, a storage appliance. For example,the storage appliance may include a Dell EMC CloudBoost appliance,although any suitable appliance is contemplated. In addition, the backupapplication 152 may provide a variety of useful functionalities such assource-side data deduplication, data compression, and WAN optimizationboost performance and throughput while also possibly reducing theconsumption and cost of network bandwidth and cloud storage capacity.One, some, or all, of these functions of the backup application 152 maybe performed using deduplication logic via deduplication module 155. Forexample, the deduplication module 155 can provide data segmentation, aswell as in-flight encryption as the data is sent by the storageapplication 152 to the clustered storage system 180. However, as furtherdescribed herein, in some embodiments, data deduplication may beperformed entirely within the clustered storage environment 180. Itshould be noted that the backup application (or storage appliance) 152can be implemented in various forms, such as a virtual, physical, ornative public cloud appliance to fit the requirements of a particularconfiguration, and the backup application 152 can be used with varioustypes of data protection environments, including public and privateobject storage clouds.

The clustered storage system 180 (as further described herein) may storebackup files 161 (or backup objects) within a one or more nodes (asfurther described herein). As shown, the clustered storage system 180may also store metadata 162 for (or associated with) the backup files161, and one or more instances of a filesystem 131 that catalogs backupfiles and other data residing in the clustered environment. In general,the storage of backup files 161 may be configured to store client system110 data backups that can be restored in the event of a loss of data.The clustered storage system 180 may be an object storage system thatincludes object storage 180-1 (as further described herein).

As shown in FIG. 1B, a cloud-based system platform 190 (such as, forexample, a Kubernetes cloud computing environment) may provide for thedeployment of various types of microservices. The platform 190 may allowfor the deployment of a plurality of verification services 192 fordetermining whether relationships between objects in object storage180-1 are still valid. As shown in FIG. 1C, various types ofverification microservices 192 may be a verification controller 192-1(“controller module”) and a verification worker(s) 192-2 (“workernode(s)”).

As shown in FIG. 1D, the verification microservice engine 194 may beincluded within the backup component 150. The verification microserviceengine 194 includes a worker estimation module 195 that estimates anoptimal amount of worker nodes to be instantiated. A verification pathmodule 197 includes a similarity group path module 197-1 to execute thesimilarity group verification path based on detection of a similaritygroup verification path condition. The verification path module 197 alsoincludes a slice recipe path module 197-2 to execute the slice recipeverification path. The slice recipe verification path is executed basedon detection of a slice recipe verification path condition. A controllerdeployment module 196-1 instantiates a controller module 192-1 toperform controller module functionalities. The controller deploymentmodule 196-1 also deploys the controller module 192-1 to the platform190. A worker deployment module 196-2 instantiates one or more workernodes 192-2 to perform worker node functionalities. The workerdeployment module 196-2 also deploys the one or more worker nodes 192-2to the platform 190. The verification microservice engine 194 includes atesting tool module 198 with an upload object module 198-1, averification tool module 198-2 and a corrupt and delete module 198-3.

Object Recipes, Slice Recipes, Similarity Groups & Compression Regions

As shown in FIG. 2, a portion of object storage 180-1 may include aplurality of object recipes 202 (obj1, obj2, obj3), a plurality of slicerecipes 204 (sl1 sl2, sl3), a plurality of similarity groups 206 (sg1,sg2, sg3, sg4) and a plurality of compressions regions 208 (cr1, cr2,cr3, cr4, cr5). In various embodiments, when a customer's object iswritten to a microservice via a client, the object is split or dividedinto one or more parts—or sets of segments. A fingerprint is computedfor each segment from the object. In other words, an object part mayhave multiple segments and a fingerprint is computed for each segment ofthe object part. Thus, each fingerprint maps to a segment of an objectpart. Lists of fingerprints are organized into slice recipes.Specifically, a slice recipe may include an array of fingerprints andsizes of segments that correspond to each respective fingerprint in thearray. A sketch may then be computed for each slice recipe according toone or more sketch algorithms.

Slice recipes may then be organized into similarity groups.Specifically, a similarity group may include one or more slice recipesthat have the same computed sketch. Stated differently, slice recipesare similar to each other if they have the same sketch. An objectrecipe, then, forms a one-to-one mapping to customer objects andreferences the one or more slice recipes associated with the object,since the associated slice recipes are based on an array of fingerprintsof the object's segment(s). The actual segments that are uniqueaccording to the deduplication service may be stored in in a compressedformat in the compression regions.

Each object has a corresponding object recipe. The object recipe may beidentified based on the name given to an object by the customer or useror by an object recipe naming convention that references thecorresponding object and the object's data domain. In a specificembodiment, a name of the object recipe is generated by obtaining a nameof an object (as provided by the user) and concatenating, augmenting, ortagging the object name with additional metadata or tags to form thename of the object recipe.

Data Structures, Metadata & Naming Conventions

As shown in FIG. 3, a diagram 300 illustrates an object recipe datastructure 302 and a slice recipe data structure 304. The object recipedata structure 302 has metadata that indicates the number of parts of anobject's data and an array stores metadata indicating how many slices ofobject data make up each individual object data part. Each slice mayinclude one or more segments of object data, such as 8 KB of data. Theslice recipe data structure 304 metadata further includes an internalreference variable indicating, for each object part indexed in thearray, how many total slices correspond to that object part index.

Each object recipe has an object recipe name 302-1 that is a string inan object naming convention 302-2 (or object name format). The objectnaming convention 302-2 includes the object's data domain (“DD”), thedata domain identifier (“ddid”), the object identifier (“OBJ”), customerdata (“userbucketname,” “userobjname”) and an object version number(“objversion”). According to various embodiments, a data domain mayrepresent a product line or be a pre-assigned unique prefix.

The slice recipe data structure 304 includes metadata that includes areference to a similarity group and a fingerprint array. The referenceto the similarity group indicates a “slice recipe-to-similarity group”relationship. As described above, fingerprints are computed for eachdata segment from an object. The fingerprint array, then, includes anarray of the fingerprints for those fingerprints included in a slice andthe fingerprint further includes the sizes of each segment representedby a fingerprint. The slice recipe also identifies the object data partto which the particular slice belongs.

Each slice recipe has a slice recipe name 304-1 that is a string in aslice recipe naming convention 304-2 (or slice recipe name format). Theslice recipe naming convention 302-2 includes the slice recipe's datadomain (“DD”), the data domain identifier (“ddid”), a slice recipeidentifier (“SL”), customer data (“userobjname”), the version number(“objversion”) as was well indicating the object part (“P< . . . >”), anindication of which slice (from the slices for the object part) theslice recipe pertains (“S< . . . >”) and a similarity group identifier(“G< . . . >”) for the similarity group referenced in the slice recipedata structure 304.

As shown in FIG. 4, a diagram 400 illustrates a similarity group datastructure 402 and a compression region data structure 404. Thesimilarity group data structure 402 has metadata that includes a uniquesimilarity group identifier. While a similarity group may referencemultiple compression regions, each compression region itself is onlyreferenced by a single similarity group. The similarity group datastructure 402 metadata also includes an array of structures. Eachstructure includes a name of an underlying compression region namefollowed by a fingerprint array and corresponding segment sizes. Actualdata segments (i.e. those data segments included in respective slicesand represented by a specific fingerprint) that have been determined tobe unique may be stored in a compressed format in a compression region,which is uniquely identified by its own compression region name—which isincluded in the similarity group data structure 402 metadata alsoincludes an array of structures. Each compression region name in themetadata thereby indicates a “similarity group-to-compression region”relationship.

Each similarity group has a similarity group name 402-1 that is a stringin a similarity group naming convention 402-2 (or similarity group nameformat). The similarity group naming convention 402-2 includes thesimilarity group's data domain (“DD”), which is a predetermined prefixstring, the data domain identifier (“ddid”), a similarity groupidentifier (“SG”) which indicates the object being identified is asimilarity group and that similarity group's actual identifier (“G”).

The compression region data structure 404 includes compressed uniquedata segments and the compressed data segment's correspond fingerprintand segment size. Each compression region has a compression region name404-1 that is a string in a compression region naming convention 404-2(or compression region name format). The compression region namingconvention 404-2 includes the compression region's data domain (“DD”),the data domain identifier (“ddid”), a compression region identifier(“CR”), and the user identifier (“Uid”). According to variousembodiments, the “Uid” may be a hash value calculated over a fingerprintand segment size array which is used for a compression region name.

As shown in FIG. 5, a condition (such as the worker node memorycondition) must occur in order for the controller module 192-1 to selectthe slice recipe verification path or the similarity group verification.The worker node condition is detected when the amount of worker nodememory required to store similarity groups exceeds the amount of workernode memory required to store all slice recipe names. When the workernode condition occurs, the controller module 192-1 selects the slicerecipe verification path. Absence of the worker node conditionrepresents that storing similarity groups in worker node memory requiresless available worker node memory than storing all the slice recipenames. Based upon absence of the worker node condition, the controllermodule 192-1 selects the similarity group verification path. That is,the similarity group verification path is selected based on determiningthat the amount of worker node memory required to store similaritygroups is less than the amount of worker node memory required to storeall slice recipe names. In some embodiments, the controller module 192-1may select the slice recipe verification while the controller module192-1 is tallying the worker node memory partitions for storingsimilarity groups referenced in the slice recipe names in object storage180-1. The controller module 192-1 may detect that the total amount ofmemory from worker node memory partitions currently identified for asubset of the referenced similarity groups already exceeds the totalamount of memory from worker node memory partitions for storing slicerecipe names—even though controller module 192-1 has not completedtallying worker node memory partitions required for storing allreferenced similarity groups.

As shown in FIG. 6A, method 600 includes at step 602, the verificationmicroservice engine 194 generates a controller module to determine atotal memory size of slice recipe names in object storage of adeduplicated storage system, wherein each slice recipe name references asimilarity group. For example, the controller module 192-1 may access amemory size of each slice recipe name string stored in object storage180-1. The controller module 192-1 may aggregate the memory sizes ofeach slice recipe name string in order to calculate the total memorysize of the slice recipe names.

At step 604, the verification microservice engine 194 generates thecontroller module to identify, for each respective worker node to beinstantiated by the controller module 192-1, one or more partitions ofworker node memory required to store each slice recipe name thatreferences any similarity group preassigned to the respective workernode. However, since the slice recipe name strings each include asimilarity group identifier and worker node-to-similarity group pairingsare pre- the amount of available worker node memory that needs to bereserved to support a plurality of instantiated worker nodes can bedetermined based on the slice recipe name strings.

For example, three slice recipe name strings may each reference adifferent similarity group. However, the referenced similarity groupsmay each have a pre-assigned pairing to a same first worker node. Thecontroller module 192-1 may tally one or more partitions of availableworker node memory in the first worker node for storage of the threeslice recipe name strings. However, according to another example, if twoslice recipe name strings each reference the same similarity group witha preassigned pairing to a second worker node, then the controllermodule 192-1 may tally one or more partitions of available worker nodememory in the second worker node for storage of the two slice recipename strings. The controller module 192-1 continues similarly tallyingavailable worker node memory partitions for all slice recipe namestrings such that each worker node is instantiated with a sufficientamount of worker node memory for storing those slice recipe names thatreference similarity groups preassigned to that worker node. Thecontroller module 192-1 calculates a total memory size based on allworker node partitions that are to be used for storage of the slicerecipe names.

At step 606, the verification microservice engine 194 generates thecontroller module to identify the worker node memory condition whiletallying, for each respective worker node to be instantiated by thecontroller module 192-1, one or more of the same worker node memorypartitions previously identified for storing the slice recipe names thatmay also be used to store the referenced similarity groups that havebeen pre-assigned to the respective worker node. For example, aftercalculating the total memory size of all the worker node memorypartitions identified for the slice recipe names, the controller module192-1 then makes a subsequent pass over all of the worker nodes'available memory. In addition, the controller module 192-1 stores thetotal memory size of the worker node memory partitions for slice recipenames.

For example, for the three slice recipe name strings that reference adifferent similarity group pre-assigned to the same first worker node,the controller module 192-1 may tally one or more worker node memorypartitions in the first worker node for storage of the three similaritygroups—instead of the three slice recipe name strings. However,according to another example, for the two slice recipe name strings thatreference the same similarity group with a preassigned pairing to thesecond worker node, the controller module 192-1 may tally one or moreworker node memory partitions in the second worker node for storage ofonly the single similarity group—as opposed to both slice recipe namestrings. The controller module 192-1 continues similarly tallyingavailable worker node memory partitions for storing the similaritygroups referenced in slice recipe name strings.

The controller module 192-1 continuously compares the running tally ofthe total memory size of the worker node memory partitions reserved forthe similarity groups to the previously calculated and stored totalmemory size of worker node memory partitions for the slice recipe names.Upon detecting that the running tally of the worker node memory size forthe referenced similarity groups exceeds the total worker node memorysize for all the slice recipe names, the controller module 192-1 detectsoccurrence of the worker node memory condition and selects the slicerecipe verification path. Since the slice recipe verification path is tobe performed, the controller module 192-1 instantiates one or moreworker nodes according to the previously determined internal worker nodememory partitions for storage of the slice recipe names (step 608).

However, if the running tally of the total memory size of the workernode memory partitions for storing the similarity groups never exceedsthe total worker node memory size for the slice recipe names, thecontroller module 192-1 determines the worker node memory condition hasnot occurred and thereby selects the similarity group verification path.Since the similarity group verification path is to be performed, thecontroller module 192-1 instantiates one or more worker nodes accordingto the internal worker node memory partitions for storage of thereferenced similarity groups (step 608).

As shown in FIG. 6B, method 610 includes at step 612, the testing toolmodule 198 includes the upload object module 198-1 which uploads one ormore objects into object storage of a deduplicated storage system,wherein the objects uploaded comprise one or more of: an object recipename, an object recipe, a slice recipe name, a slice recipe, asimilarity group name and a similarity group. For example, the uploadobject module 198-1 identifies a select number of virtual servers forrunning application within the cloud computing environment 190. Virtualserver instances are created in the amount according to the selectnumber and each virtual server instance uploads objects into objectstorage 180-1 using a synthetic data generator perfload. Each virtualserver instance uploads a certain number of objects according to apredefined ratio of a number of objects to be uploaded per number ofvirtual server instances. Each virtual server's synthetic data generatoruploading of the objects runs in parallel.

At step 614, the corrupt & delete module 198-3 of the testing tool 198corrupts internal object metadata of a first subset of the uploadedobjects, where the internal object metadata referencing data internal toan uploaded object. For example, internal object metadata may be the“part value slices X” index of an object recipe and other similarvariable and parameters within an object. Such internal object metadataexists to track and locate other object metadata and does not itselfrepresent substantive data of an object, slice recipe, similarity groupor compression region. Nonetheless, corruption of internal objectmetadata is still a concern because corrupted internal object metadatainterferes with locating and tracking substantive metadata stored in thesame object.

At step 616, the corrupt & delete module 198-3 corrupts external objectmetadata of a second subset of the uploaded objects, the external objectmetadata providing a reference to another uploaded object. For example,external object metadata is metadata stored within an object thatreferences another object or represents data stored in another object orrepresents a location or identity of another object. For example, afingerprint stored in a similarity group or a slice recipe is externalobject metadata. A reference to a similarity group stored in a slicerecipe or a compression region name stored in a similarity group arealso examples of external object metadata. At step 618, the corrupt &delete module 198-3 deletes a third subset of the uploaded objects. Forexample, the corrupt & delete module 198-3 deletes objects from objectstorage 180-1 and replaces each deleted object with its correspondingcorrupted version created by the corrupt & delete module 198-3.

According to various embodiments, a first phase of the corrupt & deletemodule 198-3 is to corrupt one or more object recipes. Object recipecorruption may include any or all of the following: adding a slice part,removing a slice part, incrementing a slice count and/or decrementingthe slice count. Removal of the slice part is based on a randomlygenerated number where the random number represents the correspondingindex of “number of slices per part” of the array of the object recipeand the identified index is removed. For adding a slice part, thecorrupt & delete module 198-3 increments the corresponding index of“number of slices per part” of the array. Incrementing and decrementingthe slice count is simply adding to or subtracting one from the “partvalue slices X” parameter, respectively. Once the appropriate corruptionis made, the corrupt & delete module 198-3 removes the existing objectis deleted from object storage and the object's corrupted version isuploaded into object storage to take its place. The corrupt & deletemodule 198-3 also stores an identity of the corrupted object recipe in alocal mapping separate from the object storage 180-1.

The second phase of the corrupt & delete module 198-3 is to corrupt oneor more slice recipes. Slice recipe corruption may include corruptingfingerprints, corrupting a slice recipe name, corrupting a similaritygroup and/or a combination of corruption both a slice recipe name and asimilarity group. The corrupt & delete module 198-3 corruptsfingerprints by determining the total number of segments in the slicerecipe. A first randomly generated number (between 0 to the last indexarray) is used to identify an array index of a select segment from thetotal number of segments. Next, a second randomly generated number(between 1 and the number of fingerprints) represents how manyfingerprints to corrupt that are in the array indexed by the firstrandomly generated number. For each fingerprint starting at the firstposition up to the position represented by the second randomly generatednumber, the corrupt & delete module 198-3 corrupts each respectivefingerprint by flipping the respective fingerprint bitwise.

The corrupt & delete module 198-3 corrupts a slice recipe name byincrementing the similarity group identifier (“G<unit32>”). However, ifthe similarity group identifier is represented by a maximum value, thecorrupt & delete module 198-3 decrements the max similarity groupidentifier. The corrupt & delete module 198-3 corrupts the similaritygroup reference stored within the slice recipe by incrementing ordecrementing the similarity group reference. The corrupt & delete module198-3 also stores an identity of the corrupted slice recipe in the localmapping separate from the object storage 180-1. Once the appropriatecorruption is made, the original slice recipe is deleted from objectstorage and replaced with the corrupted version of the slice recipe.

The third phase of the corrupt & delete module 198-3 is to corrupt oneor more similarity groups. The corrupt & delete module 198-3 corruptsone or more compression region names in a similarity group and/or one ormore fingerprints stored in the similarity group. The corrupt & deletemodule 198-3 corrupts a compression region name stored in the similaritygroup by determining the number of compression regions to corruptaccording to a randomly generated number. For each compression regionname to corrupt, the corrupt & delete module 198-3 accesses itsrespective compression region hash and switches the positions of thefirst half of the hash and the second half of the hash (i.e. 123456becomes 456123).

The corrupt & delete module 198-3 corrupts one or more fingerprints in asimilarity group according to a randomly generated compression regionindex that maps to a compression region name associated with afingerprint array in the similarity group's array of structures. Invarious embodiments, the randomly generated numbers for the compressionregion index may have a maximum limit. A first randomly generated numberby the corrupt & delete module 198-3 represents a segment index and asecond randomly generated number represents a total number offingerprints to corrupt where fingerprints to be corrupted areassociated with the first randomly generated segment index. For eachfingerprint up to the second randomly generated, each respectivefingerprint is flipped bitwise. Once the fingerprints are corrupted, thecorrupt & delete module 198-3 increments the similarity group'stransaction identifier in order to represent that the corruptedsimilarity group associated with the incremented transaction identifieris the latest version of the similarity group in object storage 180-1.The corrupt & delete module 198-3 stores an identity of the corruptedsimilarity group in the local mapping.

At step 620, the verification tool module 198-2 of the testing tool 198performs a slice recipe verification path or a similarity groupverification path over the object storage 180-1 which includes thecorrupted objects created by the corrupt & delete module 198-3. At step622, the testing tool 198 receives a corrupted objects list describingone or more corruptions identified by a controller module and one ormore worker nodes during performance of a respective verification pathtriggered by the verification tool module 198-2. At step 624, thetesting tool confirms whether the corruptions in the corrupted objectslist correspond with the first and second subsets of corrupted uploadedobjects and the third subset of deleted uploaded objects. For example,the testing tool 198 compares the received corrupted object list withthe local mapping created by the corrupt & delete module 198-3 whichdescribes the various objects that were corrupted and the corruptionsthat were performed. If the received corrupted object list matches thecorrupt & delete module's 198-3 local mapping, the testing tool 198provides a notification that the performed verification path wasexecuted correctly. If the received corrupted object list does not matchthe corrupt & delete module's 198-3 local mapping, the testing tool 198provides a notification that the performed verification path was notexecuted correctly with a list of all potentially corrupted objects.

As shown in a diagram 700 of FIG. 7, a first slice recipe name 702references similarity group 1 (SG1), a second slice recipe name 704references similarity group 2 (SG2), a third slice recipe name 706references similarity group 3 (SG3), a fourth slice recipe name 708references SG2, a fifth slice recipe name 710 also references SG2, asixth slice recipe name 712 references similarity group 4 (SG4) and aseventh slice recipe name 714 also references similarity group 1 (SG4).A first worker node has been pre-assigned pairings 712, 714, 716 to SG1,SG2 and SG3. A second worker node has been pre-assigned pairings 720,722 to SG4.

The controller module 192-1 performs a first pass of available workernode memory 724-1 and identifies a total amount of worker node memoryfrom memory partitions in the first worker node for storing the slicerecipe names 702, 704, 706, 708, 710 that reference the similaritygroups (SG1, SG2, SG3) to which the first worker node has beenpreassigned. The controller module 192-1 identifies a total amount ofworker node memory from memory partitions in the second worker node tostore the slice recipe names 712, 714 that reference the fourthsimilarity group (SG4) to which the second worker node has beenpreassigned.

Once the controller module 192-1 has identified worker node memorypartitions for all the slice recipe names, the controller module 192-1performs a second pass of the available worker node memory 724-2 withoutregard to the worker node memory partitions identified during the firstpass 724-1. During the second pass 724-2, the controller module 192-1identifies memory partitions in the first worker for storing thesimilarity groups (SG1, SG2, SG3) referenced in the slice recipe names702, 704, 706, 708, 710 since those similarity groups (SG1, SG2, SG3)have been preassigned to the first worker node. The controller module192-1 identifies memory partitions in the second worker node for storingthe fourth similarity group (SG4) referenced in the sixth and seventhslice recipe names 712, 714 since the second worker node has beenpreassigned a pairing 722 with SG4. The controller module 192-1instantiates the first and second worker nodes according to the workernode memory partitions identified during the first pass 724-1 if theslice recipe verification path is selected. However, the controllermodule 192-1 instantiates the first and second worker nodes according tothe worker node memory partitions identified during the second pass724-2 if the similarity group verification path is selected.

Exemplary Computing System

FIG. 8 shows a block diagram of an example of a computing system thatmay be used in conjunction with one or more embodiments of thedisclosure. For example, computing system 800 (or system, or server, orcomputing device, or device) may represent any of the devices or systemsdescribed herein that perform any of the processes, operations, ormethods of the disclosure. Note that while the computing system 800illustrates various components, it is not intended to represent anyparticular architecture or manner of interconnecting the components assuch details are not germane to the present disclosure. It will also beappreciated that other types of systems that have fewer or morecomponents than shown may also be used with the present disclosure.

As shown, the computing system 800 may include a bus 805 which may becoupled to a processor 810, ROM (Read Only Memory) 820, RAM (or volatilememory) 825, and storage (or non-volatile memory) 830. The processor(s)810 may retrieve stored instructions from one or more of the memories820, 825, and 830 and execute the instructions to perform processes,operations, or methods described herein. These memories representexamples of a non-transitory computer-readable medium (ormachine-readable medium, a computer program product, etc.) containinginstructions (or program code) which when executed by a processor (orsystem, device, etc.), cause the processor to perform operations,processes, or methods described herein.

As referred to herein, for example, with reference to the claims, aprocessor may include one or more processors. Moreover, the one or moreprocessors 810 may perform operations in an on-demand or “cloudcomputing” environment or as a service (e.g. within a “software as aservice” (SaaS) implementation). Accordingly, the performance ofoperations may be distributed among the one or more processors 810,whether residing only within a single machine or deployed across anumber of machines. For example, the one or more processors 810 may belocated in a single geographic location (e.g. within a home environment,an office environment, or a server farm), or may be distributed across anumber of geographic locations. The RAM 825 may be implemented as, forexample, dynamic RAM (DRAM), or other types of memory that require powercontinually in order to refresh or maintain the data in the memory.Storage 830 may include, for example, magnetic, semiconductor, tape,optical, removable, non-removable, and other types of storage thatmaintain data even after power is removed from the system. It should beappreciated that storage 830 may be remote from the system (e.g.accessible via a network).

A display controller 850 may be coupled to the bus 805 in order toreceive display data to be displayed on a display device 855, which candisplay any one of the user interface features or embodiments describedherein and may be a local or a remote display device. The computingsystem 800 may also include one or more input/output (I/O) components865 including mice, keyboards, touch screen, network interfaces,printers, speakers, and other devices. Typically, the input/outputcomponents 865 are coupled to the system through an input/outputcontroller 860.

Program code 870 may represent any of the instructions, applications,software, libraries, toolkits, modules, components, engines, units,functions, logic, etc. as described herein. Program code 870 may reside,completely or at least partially, within the memories described herein(e.g. non-transitory computer-readable media), or within a processorduring execution thereof by the computing system. Program code 870 mayinclude both machine code, such as produced by a compiler, and filescontaining higher-level or intermediate code that may be executed by acomputing system or other data processing apparatus (or machine) usingan interpreter. In addition, program code 870 can be implemented assoftware, firmware, or functional circuitry within the computing system,or as combinations thereof. Program code 870 may also be downloaded, inwhole or in part, through the use of a software development kit ortoolkit that enables the creation and implementation of the describedembodiments.

Moreover, any of the disclosed embodiments may be embodied in varioustypes of hardware, software, firmware, and combinations thereof. Forexample, some techniques disclosed herein may be implemented, at leastin part, by non-transitory computer-readable media that include programinstructions, state information, etc., for performing various methodsand operations described herein.

It should be noted that references to ordinal numbers such as “first,”“second,” “third,” etc., may indicate an adjective for an element (e.g.any noun in the application). The use of ordinal numbers does notnecessarily imply or create any particular ordering of the elements norlimit any element to being only a single element unless expresslydisclosed, such as by the use of the terms “before,” “after,” “single,”and other such terminology. Rather, the use of ordinal numbers is todistinguish between the elements. By way of an example, a first elementis distinct from a second element, and the first element may encompassmore than one element and succeed (or precede) the second element in anordering of elements. In addition, the use of the term “or” indicates aninclusive or (e.g. and/or) unless otherwise specified. For example, thephrase “at least one of x, y, or z” means any one of x, y, and z, aswell as any combination thereof. In addition, the term “based on” isused to describe one or more factors that affect a determination. Theseterms do not foreclose additional factors that may affect adetermination. For example, the phrase “determining A based on B”includes B being a factor that affects the determination of A, and doesnot foreclose the determination of A from also being based on C.However, in other instances, A may be determined based solely on B, suchas by the use of the terms “only,” “solely,” and other such terminology.In addition, the term “approximately” or “substantially” may be usedherein and may be interpreted as “as nearly as practicable,” “withintechnical limitations,” and the like.

Other embodiments of the disclosure will be apparent to those skilled inthe art from consideration of the specification and practice of theinvention disclosed herein. It is intended that the specification andexamples be considered as examples only, with a true scope and spirit ofthe embodiments being indicated by the claims.

What is claimed is:
 1. A computer-implemented method, comprising:uploading one or more objects into object storage of a deduplicatedstorage system, the objects having one or more of an object recipe name,an object recipe, a slice recipe name, a slice recipe, a similaritygroup name and a similarity group; corrupting metadata in respectivesubsets of the uploaded objects; performing a slice recipe verificationpath or a similarity group verification path over the object storage;receiving a corrupted objects list describing one or more corruptionsidentified by a controller module and one or more worker nodes duringperformance of a respective verification path; and confirming whetherthe identified corruptions in the corrupted objects list resulting fromperformance of the respective verification path correspond with thecorrupted metadata in the respective subsets of the uploaded objects. 2.The computer-implemented method of claim 1, wherein corrupting metadatain respective subsets of the uploaded objects comprises: generating afirst subset of corrupted versions of the uploaded objects by corruptinginternal object metadata of a first subset of the uploaded objects, theinternal object metadata referencing data internal to an uploadedobject; generating a second subset of corrupted versions of the uploadedobjects by corrupting external object metadata of a second subset of theuploaded objects, the external object metadata providing a reference toanother uploaded object, wherein the first and second subsets ofuploaded objects may share at least one common uploaded object; deletinga third subset of the uploaded objects; and creating a local mappingidentifying each respective corrupted object version.
 3. Thecomputer-implemented method of claim 2, wherein confirming whether theidentified corruptions in the corrupted objects list resulting fromperformance of the respective verification path correspond with thecorrupted metadata in the respective subsets of the uploaded objectscomprises: receiving the corrupted objects list based on completion ofthe slice recipe verification path or the similarity group verificationpath over the object storage; comparing the local mapping to thecorrupted objects list; and determining the performed verification pathexecuted correctly based on the corrupted objects list matching thelocal mapping.
 4. The computer-implemented method of claim 2, whereindeleting a third subset of the uploaded objects comprises: removing eachuploaded objected that has a respective corrupted version from objectstorage; and replacing each removed uploaded objected in object storagewith its respective corrupted version.
 5. The computer-implementedmethod of claim 1, wherein corrupting metadata in respective subsets ofthe uploaded objects comprises at least one of: corrupting at least oneof a slice part and a slice count stored in a data structure of anobject recipe, wherein the slice part comprises internal metadata of theobject recipe.
 6. The computer-implemented method of claim 1, whereincorrupting metadata in respective subsets of the uploaded objectscomprises at least one of: corrupting at least one fingerprint and asimilarity group reference stored within a data structure of a slicerecipe; and corrupting similarity group identifier in a slice recipestring name of the slice recipe.
 7. The computer-implemented method ofclaim 1, wherein corrupting metadata in respective subsets of theuploaded objects comprises at least one of: corrupting at least onecompression region name and at least one fingerprint stored within adata structure of a similarity group.
 8. A system comprising: one ormore processors; and a non-transitory computer readable medium storing aplurality of instructions, which when executed, cause the one or moreprocessors to: upload one or more objects into object storage of adeduplicated storage system, the objects having one or more of an objectrecipe name, an object recipe, a slice recipe name, a slice recipe, asimilarity group name and a similarity group; corrupt metadata inrespective subsets of the uploaded objects; perform a slice recipeverification path or a similarity group verification path over theobject storage; receive a corrupted objects list describing one or morecorruptions identified by a controller module and one or more workernodes during performance of a respective verification path; and confirmwhether the identified corruptions in the corrupted objects listresulting from performance of the respective verification pathcorrespond with the corrupted metadata in the respective subsets of theuploaded objects.
 9. The system of claim 8, wherein corrupt metadata inrespective subsets of the uploaded objects comprises: generate a firstsubset of corrupted versions of the uploaded objects by corruptinginternal object metadata of a first subset of the uploaded objects, theinternal object metadata referencing data internal to an uploadedobject; generate a second subset of corrupted versions of the uploadedobjects by corrupting external object metadata of a second subset of theuploaded objects, the external object metadata providing a reference toanother uploaded object, wherein the first and second subsets ofuploaded objects may share at least one common uploaded object; delete athird subset of the uploaded objects; and create a local mappingidentifying each respective corrupted object version.
 10. The system ofclaim 9, wherein confirm whether the identified corruptions in thecorrupted objects list resulting from performance of the respectiveverification path correspond with the corrupted metadata in therespective subsets of the uploaded objects comprises: receive thecorrupted objects list based on completion of the slice recipeverification path or the similarity group verification path over theobject storage; compare the local mapping to the corrupted objects list;and determine the performed verification path executed correctly basedon the corrupted objects list matching the local mapping.
 11. The systemof claim 9, wherein delete a third subset of the uploaded objectscomprises: remove each uploaded objected that has a respective corruptedversion from object storage; and replace each removed uploaded objectedin object storage with its respective corrupted version.
 12. The systemof claim 8, wherein corrupt metadata in respective subsets of theuploaded objects comprises at least one of: corrupt at least one of aslice part and a slice count stored in a data structure of an objectrecipe, wherein the slice part comprises internal metadata of the objectrecipe.
 13. The system of claim 8, wherein corrupt metadata inrespective subsets of the uploaded objects comprises at least one of:corrupt at least one fingerprint and a similarity group reference storedwithin a data structure of a slice recipe; and corrupt similarity groupidentifier in a slice recipe string name of the slice recipe.
 14. Thesystem of claim 8, wherein corrupt metadata in respective subsets of theuploaded objects comprises at least one of: corrupt at least onecompression region name and at least one fingerprint stored within adata structure of a similarity group.
 15. A computer program productcomprising a non-transitory computer-readable medium having acomputer-readable program code embodied therein to be executed by one ormore processors, the program code including instructions to: upload oneor more objects into object storage of a deduplicated storage system,the objects having one or more of an object recipe name, an objectrecipe, a slice recipe name, a slice recipe, a similarity group name anda similarity group; corrupt metadata in respective subsets of theuploaded objects; perform a slice recipe verification path or asimilarity group verification path over the object storage; receive acorrupted objects list describing one or more corruptions identified bya controller module and one or more worker nodes during performance of arespective verification path; and confirm whether the identifiedcorruptions in the corrupted objects list resulting from performance ofthe respective verification path correspond with the corrupted metadatain the respective subsets of the uploaded objects.
 16. The computerprogram product of claim 15, wherein corrupt metadata in respectivesubsets of the uploaded objects comprises: generate a first subset ofcorrupted versions of the uploaded objects by corrupting internal objectmetadata of a first subset of the uploaded objects, the internal objectmetadata referencing data internal to an uploaded object; generate asecond subset of corrupted versions of the uploaded objects bycorrupting external object metadata of a second subset of the uploadedobjects, the external object metadata providing a reference to anotheruploaded object, wherein the first and second subsets of uploadedobjects may share at least one common uploaded object; delete a thirdsubset of the uploaded objects; and create a local mapping identifyingeach respective corrupted object version.
 17. The computer programproduct of claim 16, wherein confirm whether the identified corruptionsin the corrupted objects list resulting from performance of therespective verification path correspond with the corrupted metadata inthe respective subsets of the uploaded objects comprises: receive thecorrupted objects list based on completion of the slice recipeverification path or the similarity group verification path over theobject storage; compare the local mapping to the corrupted objects list;and determine the performed verification path executed correctly basedon the corrupted objects list matching the local mapping.
 18. Thecomputer program product of claim 15, wherein delete a third subset ofthe uploaded objects comprises: remove each uploaded objected that has arespective corrupted version from object storage; and replace eachremoved uploaded objected in object storage with its respectivecorrupted version.
 19. The computer program product of claim 15, whereincorrupt metadata in respective subsets of the uploaded objects comprisesat least one of: corrupt at least one of a slice part and a slice countstored in a data structure of an object recipe, wherein the slice partcomprises internal metadata of the object recipe.
 20. The computerprogram product of claim 15, wherein corrupt metadata in respectivesubsets of the uploaded objects comprises at least one of: corrupt atleast one fingerprint and a similarity group reference stored within adata structure of a slice recipe; and corrupt similarity groupidentifier in a slice recipe string name of the slice recipe.
 21. Thecomputer program product of claim 15, wherein corrupt metadata inrespective subsets of the uploaded objects comprises at least one of:corrupt at least one compression region name and at least onefingerprint stored within a data structure of a similarity group.